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ABSTRACT 

The Mission Operations and Data Systems Directorate ( MO&DSD ) has embarked on a new 
approach for developing and operating Ground Data Systems (GDS) for flight mission support . 
t his approach is driven by the goals of minimizing cost and maximizing customer satisfaction. 
Achievement of these goals is realized through the use of a standard set of capabilities which can be 
modified to meet specific user needs. This approach, which is called the Renaissance architecture, 
S/Yaat^ai en t>i nee ring of integrated systems, based upon workstation! local area network 
uii jlfipeserver technology and reusable hardware and software components called "building 
blocks." These building blocks are integrated with mission specific capabilities to build the GDS 
for each individual mission. The building block approach is key to the reduction of development 
costs and schedules. Also, the Renaissance approach allows the integration of GDS functions that 
were previously provided via separate multi-mission facilities. With the Renaissance architecture 
the GDS can be developed and operated by the MO&DSD or all, or part, of the GDS can be 
operated by the user at their facility. Flexibility in operation configuration allows both selection of 
a cost-effective operations approach and the capability for customizing operations to user needs. 
Thus the focus of the MO&DSD is shifted from operating systems that we have built to building 
systems and, optionally, operations as separate services. 

Renaissance is actually a continuous process. Both the building blocks and the system architecture 
will evolve as user needs and technology change. Providing GDS on a per user basis enables this 
continuous refinement of the development process and product and allows the MO&DSD to remain 
or S a nization. This paper will present the activities and results of the 
MO&DSD initial efforts toward the establishment of the Renaissance approach for the development 
of GDS, with a particular focus on both the technical and process implications posed bv 
Renaissance to the MO&DSD. 

INTRODUCTION 

The MO&DSD provides end-to-end mission support for National Aeronautics and Space 
Administration (NASA) low earth orbit scientific space flight projects. This support ranges from 
establishing the radio frequency (RF) link with the user spacecraft for data acquisition, tracking 
and spacecraft commanding to distribution of captured instrument data to scientific investigators. 
In meeting its charter over the last three decades, the MO&DSD developed significant expertise 
within its organizational elements in building and operating systems to meet requirements in these 
functional areas. As an example, flight dynamics support is provided by one MO&DSD Division. 
That Division builds and operates institutional, multi-mission systems to support flight missions. 
Other Divisions are responsible for other areas of support. In general, Division systems were 
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housed in multi-mission facilities and based on large mainframe computer architectures, to provide 
efficient and cost-effective ground support operations for missions. 

These MO&DSD systems and services reflect a technology environment where large computers 
provided the only viable system solutions, and a science environment that often advocated large 
and complex science objectives and correspondingly complex spacecraft. But now both the 
nature of the users and the technology environment have changed significantly. NASA science 
programs have embraced the "faster, better, cheaper" philosophy as a means of survival in the 
present fiscally constrained environment. Smaller spacecraft are being built with substantially 
reduced budgets and development schedules from those of their predecessors. At the same time, 
the modem computer technology trend is embodied in small, powerful workstations connected via 
a network in appropriate configurations to meet specific processing needs. This combination of 
smaller missions and flexible technology has created enormous opportunity for users and providers 
to find innovative ways of doing business. 


BACKGROUND 

Drivers for change within MO&DSD have come from numerous sources, both external and internal 
to the MO&DSD. Acknowledgment of these led the MO&DSD to actively and collectively seek 
new ways of serving its customers’ needs. The drivers and initial analysis activities targeted at 
addressing the consequent challenges are discussed. 

External Drivers for Change 

The nature of the newer scientific missions and the prevailing technology have led to a desire and 
ability on the users part not just to receive data, but to actually operate all or part of the ground data 
system in order to meet the objectives of their missions. The MO&DSD past approach to mission 
operations with shared institutional systems does not possess the flexibility to meet such changes 
in customer needs. Chiefly, because this approach ties solutions for all users to a common 
technology, it also does not possess the resiliency to implement cheaper, streamlined systems for 
mission support where these are appropriate. In addition, customers have felt that dealing with 
several separate multi-mission facilities added complexity in dealing with MO&DSD for mission 
support. This is especially true for the smaller and simpler space flight projects that tended toward 
a more consolidated approach for mission and science planning and operations. Finally, with the 
dramatic reduction in the cost of computing power resulting from the evolution of data processing 
technology, the previous cost advantage of the multi-mission approach based upon mainframe 
computer architectures has evaporated. Flight project customers perceive the MO&DSD past 
approach to mission operations as not being the most cost-effective. 

Internal Drivers for Change 

Recent downsizings of mission budgets coupled with the availability of rapid technology 
advancements have led the organizational elements within MO&DSD to seek alternate solutions for 
development and operation of ground data systems within their functional areas. Utilization of 
workstation/LAN architectures, formalized software reuse, and adoption of commercial standards 
have all been successfully demonstrated within the Divisions for several years. For example, a 
paper published in the SPACEOPS 92 Proceedings entitled "SAMPEX Payload Operations 
Control Center Implementation" described the first development of a Payload Operations Control 
Center (POCC) based upon the Transportable POCC (TPOCC) architecture. These technology 
innovations have been beneficial and demonstrated significant cost savings. However, before 
Renaissance they remained generally localized within the various MO&DSD facilities. While there 
were benefits that accrued from collaboration across Division facilities, they had not yet gained 
supremacy as a standard way of accomplishing the MO&DSD mission. 
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Architecture Analysis Activities 

Recognizing these drivers, the MO&DSD initiated activities to explore new, consolidated 
approaches for development and operation of GDS for flight mission support. The goals of 
minimizing cost, maximizing flexibility for meeting customer requirements, and reducing 
complexity were established for this effort. A study was commissioned to identify GDS 
architecture approaches that offer significant reductions in cost and development schedules as well 
as increased flexibility for meeting individual customer requirements in establishing mission 
upport capabilities. The report recommended an architecture approach that addressed 
implementations from simple to complex missions through integration of support functions in a 
mission-specific instantiation. Implementations would employ reuse over multiple missions and 
incorporate effective standards for commercial product inclusion 

An Architectural Steering Group (AS G) was established to evaluate the recommendations from the 
architecture study report and to determine if the scope of the study should be expanded to address 
space-to-ground and ground-to-ground communications mission support functions. The ASG also 
chose to commission two additional studies: to look at current and future Directorate operations 
concepts to assure that operations as well as development improvements would be realized in the 
new architecture. The ASG activities ultimately led to the identification of an ^chS approach 
that stressed the engineering of integrated systems that encompassed the MO&DSD mission 
support functions of flight dynamics, spacecraft command and control, and data capture and 
distribution. These systems would be based on workstation/LAN/fileserver technology and 
reusable hardware and software components called building blocks. The name "Renaissance" was 
pplied to this architecture approach. ("Renaissance" is an acronym that stands for Reusable 

En^onments i ' Th? Ter” Int ' r ° pen * h u PaC u Sde . nCe ’ Anal y sis - Navigation, and Control 
5 m ? u tS ) , The ASG also detemnned that the institutional nature of communication services 

s ould not be changed, though in fact the technology of implementing these services will be 
improved as Renaissance evolves. 


THE RENAISSANCE CONCEPT 

The MO&DSD has embraced change through Renaissance on two fronts. First, is willing to view 
itself as a provider of both systems and services, rather than primarily a provider of services 
Secondly, is the espousal of particular objectives to facilitate achievement of Renaissance. 

MO&DSD Renaissance Services 

Renaissance divides the domain of MO&DSD mission support capabilities into three areas: mission 
operations, science operations, and centers of expertise (see Figure 1). 
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Figure 1. Renaissance Mission Support Domain 

Mission operations are those functions that are integrated to operate the spacecraft to meet the 
specific requirements for that mission. Similarly, science operations are integrated to achieve the 
science objectives of a specific mission. The functional elements associated with mission and 
science operations are physically embodied within a Mission Operations Center (MOC) and a 
Science Operations Center (SOC), respectively, for each flight mission. Under the Renaissance 
concept, the MOC and the SOC could be integrated into a single center, collocated in a shared 
facility, or geographically dispersed. There is no requirement that either be located at the Goddard 
Space Flight Center (GSFC). 

The third area of the MO&DSD domain, the Centers of Expertise (COE), comprise a permanent 
institutional infrastructure that contains the resources to support the set of flight missions over their 
entire life cycle. Obviously, the key resource within the COE is the personnel with the technical 
skills and experience in the development and operation of GDS. The balance of the COE resources 
include the tools, materials, and processes that are applied by the personnel to develop and operate 
the mission support functions. 

Renaissance Objectives 

The Renaissance architecture approach espouses three major objectives for achieving the goals of 
cost-effectiveness, flexibility, and simplicity for providing mission operations support to space 
flight project customers. Firstly, to assure that developed systems permit integrated operations in 
a stand-alone environment for unique mission support. Development and operation of mission- 
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s pecific systems provides maximum flexibility for customizing the GDS to meet the user’s 
particular requirements. The integration of mission support functions for command and control 
flight dynamics and data processing also presents an opportunity for reducing the cost of ground 

each of1hp e mf!? ent - th ^° Ugh tHe elln 3 ination of redundant functions that had be § en replicated^ithin 
each of the multi-mission systems, (e.g., telemetry unpacking). Developments, however would 

effective UdC rec ° mbinmg of functl0ns into multi-mission facilities if this should prove cost- 

The second objective inherent with Renaissance is reuse of support capabilities. Here reuse means 
a systematic, planned approach for developing reusable components of ground data systems rather 
™ USC °h ^ a tr° C baS1S * 11 implies well - def[ ned interfaces and use of standSs S ^Tplemem 
ai m an ablhty t0 inse « n ?w technology readily over time. The construction and use of 
t ese reusable components, or building blocks", is the key to reducing the cost of ground svstem 

bSd!s^ ment MO&DSD establish ed a Renaissance Project Team to define thCse "budding 

The third significant objective associated with Renaissance is the projectized approach to GDS 
development and operation which is aimed at reducing the complexity associated with the present 
S"^ es : .Pr™ ™ ssi °n support systems have of course been coorCatedamong 
?h V1S1 ° nS ’ but subsys ^ m s were implemented in separate facilities and not functionally 
TbC ? CW approach call , s f ? T completely integrated requirements and integrated testing y 
stablishment of a mission team, led by a Ground System Project Manager (GSPM) provides a 

MO&DSD CDS m Th^ i M ° & H D r D rdating the development and operTon of 

T e * ani deflnes the mission system, and integrates reusable Renaissance 
budding blocks with mission-unique building blocks that it develops. The team also assures that 
space flight project customer needs receive strong advocacy within the MO&DSD. 

APPROACH TO ACHIEVING RENAISSANCE 

The ASG selected the Advanced Composition Explorer (ACE) mission for the initial 

ntat ‘T a Renais . sance GDS. The mid-97 launch date was close enough to provide for a 
relatively quick demonstration of Renaissance without incurring the risks related to interruption of 
system developments that were already well under way [e.g., X-Ray Timing Explorer fXTFi and 
Tropical Rainfall Measuring Mission (TRMM)J. S y iming bx P lorer rE ) and 

The challenge faced by the MO&DSD teams was to achieve the modular "building block" goals of 
enaiss^ce whde simultaneously meeting the near-term mission needs of the ACE Mission 
Schedules, climate and budget would not allow for an extended period of time to prototype 
Renaissance concepts before instantiating them in a mission. Building blocks could not be created 

Sieve d PieC6S - ParalId P athS and in « P>-n.ng werereqS to 

However, this challenge was not as daunting as it might appear. Two factors created a climate fhr 
success: Ught integration of the Renaissance and ACE%lementS^ 
availability of predecessor systems that meet Renaissance goals. 

Implementation Teams 


? core g f ou P of hi 8 hly capable engineers, was charged with 
Renaissance building block definition. Their charter was as follows: 
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• Identify building blocks through examination of ACE and other system (e.g., XTE) 
requirements to determine generic functionality. 

• Identify predecessor systems and Commercial Off-the-Shelf (COTS) products that could 
meet the building block specifications. 

• Identify standards and development processes useful in the Renaissance era. 

• Develop plans for transitioning into the Renaissance approach. 

• Work with the mission teams, initially the ACE team, to apply the Renaissance architecture. 

This core team was augmented by additional MO&DSD engineers who served to provide input to 
their efforts and to review and critique the outcomes. In particular, those engineers charged with 
implementing the ACE Mission were early and constant participants in the Renaissance effort. 

Predecessor Systems 

Despite the use of the Renaissance name to capture a system concept within the MO&DSD, many 
predecessor efforts on other missions were aligned with the Renaissance concepts, and influential 
in molding its goals and giving confidence that the architecture would be successful. The 
Renaissance concept, in fact, was merely an acceleration and consolidation of various efforts that 
were already occurring naturally within the Directorate. Reliance on these efforts gave credence to 
the possibility of meeting both ACE and Renaissance goals within the aggressive schedule. 
Examples of forerunner efforts include: 

• The TPOCC UNIX-based software that supports real-time spacecraft command and control 
and that, prior to Renaissance, was in use or planned for use for the Small Explorer 
missions (SAMPEX, FAST, SWAS), ISTP WIND, POLAR and SOHO, XTE and 
TRMM. The TPOCC brings a legacy of substantial software reuse as well as workstation 
and LAN-based processing. 

• The VLSI-based Level Zero Processor (LZP) employed on the FAST mission. This 
system captures spacecraft science data and removes transmission artifacts before 
forwarding it to science investigators. It is integrated into the mission command and 
control facility, and as such is a predecessor to the Renaissance operations approach. 

• The Packet Processor (PACOR) II distributed system, a multi-mission data capture and 
level zero processing system planned for use by SWAS, TRMM, XTE, HST and GRO. 
PACOR illustrates both system (hardware and software) reuse and distributed processing. 

• The Generic Support System (GSS), a reusable system for attitude determination. 

• The Generic Spacecraft Analyst Assistant (GenSAA), a tool that allows spacecraft analysts 
to create graphics and rule-based systems to assist in monitoring spacecraft health and 
safety, and other decision-based situations. 

• The Generic Trend Analysis System (GTAS), a reusable spacecraft trending tool. 

All of these systems support in some measure the Renaissance objectives of reusability and 
integrated, stand-alone systems. Figures 2 and 3 capture the extent to which these goals are met in 
missions prior to ACE. 
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Figure 2. Percent Reuse 
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Figure 3. Percent Independent of Multi-Mission Facilities 
ACHIEVEMENTS TO DATE 


Pr^!L?T OItS have P artition ed the Renaissance GDS into four sets of services 
Project Team working group is defining functionality and building blocks f< 
groupings are as follows: 6 


A Renaissance 
each set. The 
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• Spacecraft Communication Services (reconstruction of telemetry packets, command 
transmission, packet annotation, time correlation, and archiving). 

• Spacecraft Data Distribution Services (real-time, quick-look and routine data delivery, data 
subsetting, output logging, and delivery validation). 

• User Services (user interface, user tools and application builders, system configuration and 
monitoring, system security, system time synchronization, and data management). 

• Application Services (spacecraft services such as telemetry monitoring, trend analysis, 
attitude support, command verification; planning and scheduling applications for 
spacecraft, science and network activity planning; and uplink applications such as real-time 
commanding and load generation). 

Two additional working groups are assigned to issues that cross all Renaissance services: 

• Architecture group, charged with defining the integrated architecture. 

• Simulation and testing. 

Many of the promised innovations of Renaissance are being realized within the context of the ACE 
ground system, including largely integrated operations, consolidation of functionality, 
incorporation of new technology and standards, and reliance on the legacy of past systems. Figure 
4 illustrates the architecture proposed for ACE. 

Integrated Operations 

It is intended to incorporate real-time command and control, command and load generation, attitude 
determination and data capture and distribution within the ACE mission operations center. The 
only major MO&DSD ground system function that will still be treated within a separate facility for 
this mission is orbit determination and the ancillary production of maneuver planning aids. The 
ground station and SOC will remain separate from the MOC. (These facilities are not implemented 
by MO&DSD and are traditionally separated from MO&DSD facilities. Future directions will lead 
to the consolidation of MOC and SOC functions. See, for example, related paper in this 
conference, “A New Systems Engineering Approach to Streamlined Science and Mission 
Operations for the Far Ultraviolet Spectroscopic Explorer (FUSE).” 

Consolidation of Functionality 

In two significant arenas, functionality previously developed and performed within multiple 
facilities will be consolidated. Firstly, there will be a single front-end for frame synchronization, 
Reed-Solomon processing, virtual channel separation, and data quality annotation. This front-end 
will be located at the Deep Space Network (DSN) ground station (vs. former performance of 
portions of this function in three MO&DSD facilities). Data will be forwarded from there to the 
ACE MOC. This system will also allow data to be forwarded directly to the SOC for processing, 
if this proves desirable. 

Secondly, a consolidated simulator that will meet the testing needs of all ground system functions 
is planned for development 
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Figure 4. Renaissance Architecture for ACE MOC 
Incorporation of Technology and Standards 

A particular innovation within the ACE ground system is the use of the commercially available 
Transmission Control Protocol/Internet protocol (TCP/IP) protocol to transmit data from the 

cA^ tatl ° n t0 - • MOC * This allows replacement or encapsulation of the traditional 4800 -bit 
NASA Communications (Nascom) blocks, and eliminates the need for custom systems to handle 
these blocks. Use of this protocol paves the way to ultimately reduce institutional cost for 
providing ground communications because of wide commercial availability and ability to eliminate 
Nascom blocks in the future. J 

The ACE ground data system will consist of a series of workstations supporting POSIX and 
communicating via a LAN. Software will be developed in ANSI C, C++ or Ada While each 
workstation will have particular functionality assigned to it, the ability to move functions among 
workstations for load balancing or recovery from anomalies will be supported. 
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The ground system will also use X-windows and MOTIF as interface standards. 

Predecessor Systems 

The ACE ground system will depend heavily on building blocks, either implemented particularly to 
support ACE as the first mission, or derived from predecessor systems within MO&DSD. Table 1 
lists ACE services and their derivation. 


CONCLUSION 

The consolidated Renaissance effort is less than a year old. Progress is substantial, however, due 
to an aggressive project team and integration of predecessor systems already aligned with 
Renaissance goals. Reliance on Renaissance products is allowing the MO&DSD to work with its 
customers in defining low-cost systems whose operations are tailored to the customers needs, for 
example, with the FUSE and the upcoming Small Explorer missions. Early results are promising, 
and the Directorate is committed to sustaining a management approach that will allow Renaissance 
goals to be achieved. 



Table 1. Derivations of Renaissance Services for ACE 
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Nomenclature 


ACE 

Advanced Composition Explorer 

ASG 

Architectural Steering Group 

COE 

Centers of Expertise 

COTS 

Commercial Off-the-Shelf 

DSN 

Deep Space Network 

FAST 

Fast Auroral Snapshot Explorer 

FUSE 

Far Ultraviolet Spectroscopic Explorer 

GDS 

Ground Data Systems 

GenSAA 

Generic Spacecraft Analyst Assistant 

GRO 

Gamma Ray Observatory 

GSFC 

Goddard Space Flight Center 

GSPM 

Ground System Project Manager 

GSS 

Generic Support System 

GTAS 

Generic Trend Analysis System 

HST 

Hubble Space Telescope 

ISTP 

International Solar Terrestrial Physics 

LAN 

Local Area Network 

LZP 

Level Zero Processor 

MO&DSD 

Mission Operations and Data Systems Directorate 

MOC 

Mission Operations Center 

NASA 

National Aeronautics and Space Administration 

Nascom 

NASA Communication 

PACOR 

Packet Processor 

POCC 

Payload Operations Control Center 

POLAR 

Polar Plasma Laboratory 

RENAISSANCE 

Reusable Network Architecture for Interoperable Space Science 

RF 

Radio Frequency 

SAMPEX 

Solar Anomalous and Magnetospheric Explorer 

SOC 

Science Operations Center 

SOHO 

Solar Oscillator Heliospheric Observatory 

SWAS 

Submillimeter Wave Astronomy Satellite 

TCP/IP 

Transmission Control Protocol/Internet Protocol 

TPOCC 

Transportable Payload Operations Control Center 

TRMM 

Tropical Rainfall Measuring Mission 

WIND 

International Physics Laboratory 

XTE 

X-ray Timing Explorer 
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